Field of the Invention
This invention relates to a method of operating a transaction server and to the transaction server itself.
Description of the Related Art
Transaction processing monitoring systems generally provides diagnostic capabilities. One of the most important diagnostic tools is the use of tracing within a product, to produce a chronological audit trail of events occurring within the system. In one popular transaction processing monitoring system, for example, the internal trace feature provides a rich set of unique trace points, grouped together into a large number of different trace components (for example Kernel, Storage, Dispatcher, Java virtual machine (JVM) (Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both), etc.). Users can select which of these trace components are to be set active within the system and which are to be suppressed. They can do this both statically before restarting the transaction processing system and dynamically by interacting with the transaction processing monitoring system through a trace control transaction.
Users are aware that turning tracing on and having all the trace components set to produce trace entries means that problem determination is much easier. Active tracing can assist both the users themselves, when analysing a failing user application, and also the service provider, when reviewing the documentation for a system failure. However, many users choose to run their transaction processing monitoring systems with the trace function either turned off completely, or with only a subset of the various trace components active. This is because there is a cost in central processing unit (CPU) terms (and extra instruction pathlength to be executed) whenever a trace call is made.
Since users are billed by CPU usage, and affected by response time degradation due to execution pathlengths, the users of transaction servers are keen to reduce any extra cost that can be avoided. If there is no problem to be analysed, there is no need for the transaction processing monitoring system to generate trace data, and so users will often run their transaction processing monitoring systems with little or no tracing active in order to minimise the associated tracing CPU cost and pathlength of instructions to make the trace calls. The trade-off to this approach is that if a transaction processing monitoring system or application problem subsequently occurs, the resulting debugging documentation may be insufficient to resolve the cause of the failure. This jeopardises the policy of First Failure Data Capture (FFDC), where transaction processing monitoring systems attempt to generate all the required documentation the first time a failure occurs, to avoid the need to recreate a failure and gather additional documentation for analysis.
This known exposure to FFDC means that users are interested in knowing the cost in terms of CPU/pathlength when running with transaction processing monitoring system trace active, or when using a particular selection of trace components. However, current transaction servers are unable to provide a specific quantitative answer to this question since it will vary from product release to release, and from different workload usage within a given server region. For example, a transaction processing monitoring system where applications drive many EXEC transaction processing monitoring system commands, which in turn generate many trace entries in specific trace components, will have a different CPU and pathlength cost to a system where many applications run background-type work that generates a lot of application-specific code and relatively few EXEC commands and associated trace calls. There is no specific one-size-fits-all answer that would be appropriate for all users.
Additionally, some transaction processing monitoring systems can generate monitoring data and region-specific data, which give a coarse level of CPU-usage at the region level or at individual transaction levels. However, users still need to analyse this data through post-processing tools to breakdown the CPU usage. Also, users need to run specific benchmark comparisons on their own systems to compare and then contrast CPU costs for various trace settings used for their own specific workloads. At the present time there is no simple and straightforward way to quantify the costs of selecting specific trace settings, or combinations thereof, in a user's bespoke environment. The problem to be solved is the absence of any straightforward method to quantify these costs of selecting particular trace settings and combinations of settings in individual user environments.